optimalizacia sql dotazu v MSSQL
Otázka od: peter sulek
7. 1. 2004 12:55
Zdravim Vas,
Mam tabulku TABULKA1 s danymi stlpcami: ID_Tab2, ID_Tab3, ID_Tab4, ID_Tab5,
ID_Tab6
Hlavna tabulka TABULKA1 ma priblizne 50.000 zaznamov. Kazda tabulka(
TABULKA2...TABULKA6 ) ma priblizne 15.000-20.000 zaznamov.
Select na hlavnu tabulku mam nasledujuci:
SELECT tab2.XXX, tab3.XXX, tab4.XXX, tab5.XXX, tab6.XXX FROM TABULKA1
LEFT OUTER JOIN [TABULKA2] AS Tab2
ON TABULKA1.ID_Tab2 = Tab2.ID
LEFT OUTER JOIN [TABULKA3] AS Tab3
ON TABULKA1.ID_Tab3 = Tab3.ID
LEFT OUTER JOIN [TABULKA4] AS Tab4
ON TABULKA1.ID_Tab4 = Tab4.ID
LEFT OUTER JOIN [TABULKA5] AS Tab5
ON TABULKA1.ID_Tab5 = Tab5.ID
LEFT OUTER JOIN [TABULKA6] AS Tab6
ON TABULKA1.ID_Tab6 = Tab6.ID
Ide o to ze takyto select je velmi pomaly. Na mojom PC, Intel Celeren 1,7GB,
368MB, WinXP, Delphi 6, MSSQL 2000 trva tento select priblizne 15 sekund, co
je velmi vela.
Potreboval by som poradit ako zoptimalizovat tento dotaz.
Alebo nejake sekvencne docitavania zaznamov pre zobrazenie v gride. Mozno na
toto uz existuje neaka komponenta.
Odpovedá: Ing. Pavel Zilinec
7. 1. 2004 13:12
V QA si dej pred spoustenim dotazu 'Show execution plan' a pak se
objevi nova zalozka, kde bude neco jako graf zateze.
Je mozne, ze jde pouze o spatnou volbu indexu nebo absenci potrebnych
indexu vubec.
--
ing. Pavel Zilinec
MailTo:zilinec@email.cz
Prog-Soft s.r.o. Plzen
Informacni system pro vyrobce
a distributory napoju
Wednesday, January 7, 2004, 12:33:39 PM, bylo napsano:
ps> Zdravim Vas,
ps> Mam tabulku TABULKA1 s danymi stlpcami: ID_Tab2, ID_Tab3, ID_Tab4, ID_Tab5,
ps> ID_Tab6
ps> Hlavna tabulka TABULKA1 ma priblizne 50.000 zaznamov. Kazda tabulka(
ps> TABULKA2...TABULKA6 ) ma priblizne 15.000-20.000 zaznamov.
ps> Select na hlavnu tabulku mam nasledujuci:
ps> SELECT tab2.XXX, tab3.XXX, tab4.XXX, tab5.XXX, tab6.XXX FROM TABULKA1
ps> LEFT OUTER JOIN [TABULKA2] AS Tab2
ps> ON TABULKA1.ID_Tab2 = Tab2.ID
ps> LEFT OUTER JOIN [TABULKA3] AS Tab3
ps> ON TABULKA1.ID_Tab3 = Tab3.ID
ps> LEFT OUTER JOIN [TABULKA4] AS Tab4
ps> ON TABULKA1.ID_Tab4 = Tab4.ID
ps> LEFT OUTER JOIN [TABULKA5] AS Tab5
ps> ON TABULKA1.ID_Tab5 = Tab5.ID
ps> LEFT OUTER JOIN [TABULKA6] AS Tab6
ps> ON TABULKA1.ID_Tab6 = Tab6.ID
ps> Ide o to ze takyto select je velmi pomaly. Na mojom PC, Intel Celeren
1,7GB,
ps> 368MB, WinXP, Delphi 6, MSSQL 2000 trva tento select priblizne 15 sekund,
co
ps> je velmi vela.
ps> Potreboval by som poradit ako zoptimalizovat tento dotaz.
ps> Alebo nejake sekvencne docitavania zaznamov pre zobrazenie v gride. Mozno
na
ps> toto uz existuje neaka komponenta.
Odpovedá: Lukas Suchanek
7. 1. 2004 13:59
> SELECT tab2.XXX, tab3.XXX, tab4.XXX, tab5.XXX, tab6.XXX
> FROM TABULKA1
> LEFT OUTER JOIN [TABULKA2] AS Tab2
> ON TABULKA1.ID_Tab2 = Tab2.ID
>
> LEFT OUTER JOIN [TABULKA3] AS Tab3
> ON TABULKA1.ID_Tab3 = Tab3.ID
>
> LEFT OUTER JOIN [TABULKA4] AS Tab4
> ON TABULKA1.ID_Tab4 = Tab4.ID
>
> LEFT OUTER JOIN [TABULKA5] AS Tab5
> ON TABULKA1.ID_Tab5 = Tab5.ID
>
> LEFT OUTER JOIN [TABULKA6] AS Tab6
> ON TABULKA1.ID_Tab6 = Tab6.ID
na prvni pohled nevidim zadne podminky pro vyber z TABULKA1, takze ten
select bude tahat vsechno, tedy onech cca 50k zaznamu. Nevim jak mas tu
databazi postavenou, ale pokud nemas udelany indexy nebo primarni klice na
tom Tab2..Tab6.ID, tak bych se nedivil, ze to jede tak pomalu. Dalsi zdrzeni
muze zpusobit velke mnozstvi dat v jednom radku (moc sloupcu, dlouhe
sloupce, bloby)
Ale s MSSQL nemam moc zkusenosti, v posledni dobe delam nad Informixem a
Oraclem, takze popisuju jak bych problem resil ja nad onemi DB.
/ Lukas Suchanek
Odpovedá: peter sulek
7. 1. 2004 13:42
Chcel by som vediet na co sa mam presne zamerat v Execution plan? Nie som z
toho moct mudry 
Ktore indexy by mali byt vytvorene pre dany SELECT ?
> V QA si dej pred spoustenim dotazu 'Show execution plan' a pak se
> objevi nova zalozka, kde bude neco jako graf zateze.
> Je mozne, ze jde pouze o spatnou volbu indexu nebo absenci potrebnych
> indexu vubec.
>
> --
> ing. Pavel Zilinec
> MailTo:zilinec@email.cz
Odpovedá: peter sulek
7. 1. 2004 15:31
Ono tu taka poziadavka je aby sa tahaly vsetky zaznamy z tabulky. Preto by
som aj potreboval nejake sekvencne docitavania dat, alebo nieco take, ci uz
nejaky specialny dataset alebo grid.
> na prvni pohled nevidim zadne podminky pro vyber z TABULKA1, takze ten
> select bude tahat vsechno, tedy onech cca 50k zaznamu. Nevim jak mas tu
> databazi postavenou, ale pokud nemas udelany indexy nebo primarni klice na
> tom Tab2..Tab6.ID, tak bych se nedivil, ze to jede tak pomalu. Dalsi
zdrzeni
> muze zpusobit velke mnozstvi dat v jednom radku (moc sloupcu, dlouhe
> sloupce, bloby)
> Ale s MSSQL nemam moc zkusenosti, v posledni dobe delam nad Informixem a
> Oraclem, takze popisuju jak bych problem resil ja nad onemi DB.
>
> / Lukas Suchanek
Odpovedá: Vlastimil Bardon
7. 1. 2004 15:16
1) v exekucnim planu se divej, jestli tam nekde neni table scan - on tam urcite
bude u te prvni tabulky, kterou chces celou, ale ostatni by mely pouzivat
indexy (pokud na nich indexy jsou)
2) Tahat v jednom selektu 50k zaznamu je nesmysl, na obrazovku se jich vejde
maximalne tak 50, k cemu ty ostatni potrebujes? Nicmene jestli je rychlost
zpusobena optimalizatorem, nebo mnozstvim dat, to poznas napriklad tak, ze si
ten select spustis v QA - ten Ti vraci data asynchronne, takze pokud zacne data
vracet relativne vcas ale dotaz dobehne o mnoho pozdeji, je to problem v objemu
dat, jestli ale i v QA uvidis prvni data pozde, spise to mohou byt ty indexy
3) Existuje take Index Tuning Wizard. Jeho pouziti je relativne jednoduche, ale
prece jen slozitejsi, nez abych to popisoval do mailu. Skus si to nastudovat v
helpu. Budes pak potrebovat Profiler - v nem si zvolis vhodny profil,
vygenerujes skript (spustenim nejakeho Tveho programu), ten pustis do Wizarda a
on ti sam nadela potrebne indexy
4) Upozornuji, ze nekdy muze zpomaleni jednoho dotazu zpusobit uplne jiny dotaz
spusteny jinym uzivatelem. To sice neni tento Tvuj pripad, ale pripominam to v
souvislosti s Index Tuning Wizardem, ktery by mohl preventivne pomoct i na tyto
budouci problemy
5) Specialny dataset udelat jde pokud se vytvori kursor na serveru, ale nemam s
tim uplne nejlepsi zkusenosti. Spise bych hledal chybu nekde v navrhu aplikace.
50000 radku dat na klientu je velmi nestandardni...
-----Original Message-----
From: peter sulek [mailto:sulodk@atlas.cz]
Sent: Wednesday, January 07, 2004 2:32 PM
To: delphi-l@clexpert.cz
Subject: Re: optimalizacia sql dotazu v MSSQL
Ono tu taka poziadavka je aby sa tahaly vsetky zaznamy z tabulky. Preto by
som aj potreboval nejake sekvencne docitavania dat, alebo nieco take, ci uz
nejaky specialny dataset alebo grid.
> na prvni pohled nevidim zadne podminky pro vyber z TABULKA1, takze ten
> select bude tahat vsechno, tedy onech cca 50k zaznamu. Nevim jak mas tu
> databazi postavenou, ale pokud nemas udelany indexy nebo primarni klice na
> tom Tab2..Tab6.ID, tak bych se nedivil, ze to jede tak pomalu. Dalsi
zdrzeni
> muze zpusobit velke mnozstvi dat v jednom radku (moc sloupcu, dlouhe
> sloupce, bloby)
> Ale s MSSQL nemam moc zkusenosti, v posledni dobe delam nad Informixem a
> Oraclem, takze popisuju jak bych problem resil ja nad onemi DB.
>
> / Lukas Suchanek
Odpovedá: delphin@post.cz
7. 1. 2004 15:39
> Ono tu taka poziadavka je aby sa tahaly vsetky zaznamy z tabulky. Preto by
Nemuzu si pomoct, ale 50k zaznamu bude BFU prohlizet nekolik dnu, takze 15
sekund ho nemuze rozhazet.
Odpovedá: Jakub Dusek
7. 1. 2004 15:48
Taky mi to na to mnozstvi dat nepripada jako dlouha doba.
Jakub Dusek
----------------------------------------------------------------------
web: http://www.corexpert.com, mobile: +420 604 615 795, ICQ: 86063232
odesilani smsek, vizitek, log a melodii, snadna integrace do Vaseho IS
=> Sms GateKeeper, Sms GateKeeper Service
======================================================================
Wednesday, January 7, 2004, 3:26:30 PM, you wrote:
>> Ono tu taka poziadavka je aby sa tahaly vsetky zaznamy z tabulky. Preto by
dpc> Nemuzu si pomoct, ale 50k zaznamu bude BFU prohlizet nekolik dnu, takze 15
dpc> sekund ho nemuze rozhazet.
Odpovedá: Lukas Suchanek
7. 1. 2004 16:34
Ave,
> Taky mi to na to mnozstvi dat nepripada jako dlouha doba.
> >> Ono tu taka poziadavka je aby sa tahaly vsetky zaznamy z tabulky.
> >> Preto by
> dpc> Nemuzu si pomoct, ale 50k zaznamu bude BFU prohlizet
> nekolik dnu,
> dpc> takze 15 sekund ho nemuze rozhazet.
zkratka, pokud si udelas index na tab1(ID), tab2(id),
tab3(ID),..,tab6(id) a nezrychli se to, tak ti ja uz osobne moc neporadim.
Otazka je, jestli tech 15s trva vykonani dotazu (a vraceni naplneneho
bufferu prvnimi X zaznamy z 50k) nebo vraceni vsech 50k zaznamu. To prvni by
bylo asi spatne a ten select by mel tak jako tak probehnout v radu desetin
vteriny, pokud jsi to pocital s kompletnim nactenim, tak je to mozna jeste
unosna doba, tezko soudit kdyz nevidim dovnitr.
/ Lukas Suchanek